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(54) Variable data fields in a page description language 



(57) A method of printing a set of documents which 
have a generally identical background image, and differ 
from each other by a small area, a page specific image 
region. A method is described to locate each page spe- 
cific image region in a background image page layout. A 
master file stores this background image information 
along with positional parameters and a file reference to 



the page specific image region data. The page specific 
data are stored in one or more data files, generated by 
a database application program. The master file and 
page specific f He are combined such that the background 
image is transformed to a bitmap only once, and the page 
specific data variously modify this bitmap to represent 
each individual page. 
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Description 

Field of the invention. 

The present invention relates to a method for creat- 
ing multiple documents having identical background 
image regions and document specific image regions 
containing individual data elements. The method can be 
used in desktop publishing systems and for professional 
printed matter e.g. for direct mailing or personalised cop- 
ies. 

Background of the invention. 

For direct mailing purposes or in the production of 
personalised printed matter, it is necessary to print 
between ten or one thousand documents, having the 
same contents, except for a specific small area of the 
document. Usually, a document consists of one single 
sided sheet of paper, but such a document can also con- 
sist of several single sided or even double sided sheets. 
It is also possible that several pages of such a document 
must be printed or imposed on a single sheet of paper. 
One or more imposed sheets are then fold anchor assem- 
bled in a specific order to deliver a folder or booklet with 
the required layout We will discuss here the problems 
that arise when individualised single sided sheets must 
be provided, although the current invention also solves 
these problems for the more complex configurations. 

The most simple format of an individualised single 
sided sheet comprises a general text with open spaces. 
In the open spaces, the specific data are filled in per 
page. Traditionally, this is handled in the following way : 
the general text - indicated further on as the background 
image - is printed on a plurality of sheets, which are all 
identical. The batch printing can be done by an offset 
printer, by a photocopier or by a digital printer. The page 
specific information can be added immediately after the 
first printing pass or on a later moment This can be per 
page by an individual tag stuck on the sheet, by hand 
writing, type-writing or by a printer coupled to a compu- 
ter. Such a printer can be an impact printer, electro- 
graphic laser printer, inlqet printer etc. The problems for 
this method are the visible difference in writing and 
between the ink of the background image and the ink of 
the page specific data. Moreover, the page specific text 
is usually not properly aligned with the background text 
The second pass to add the page specific data requires 
extra time and printing devices. If the background quality 
must be high, offset printing is required, which is very 
costly for small batches of individual copies. Another 
important drawback of this method is that only overwrit- 
ing is possible. Nothing from the background image can 
be locally erased. 

In the current digital output systems comprising a 
bitmap printer, for example in desktop applications, it is 
possible to generate a data stream for individual pages 
in a page description language. For each page to be 
printed, the data stream comprises a description of the 
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background image and a description of the individual 
image. For each individual page, the data stream 
describing the background image and the specific data 
must be converted to a bitmap. If the background image 

s is complex, this means an important burden for the raster 
image processor (RIP) generating the bitmap, while just 
a small portion on the sheet will be different from the pre- 
vious sheet. Moreover, the transmission per sheet of the 
data stream describing the background data, can impose 

10 a large performance reduction on the total system. If the 
transmission goes over a network, this kind of print Job 
imposes a tremendous load on the connection, thereby 
influencing the throughput of other tasks using the same 
network. 

is A method that alleviates the transmission problem 
is the creation of "forms". A page description language 
that supports the definition and use of forms is a Level 2 
feature of the Postscript page description language. 
PostScript is a trade mark of Adobe Systems Inc. The 

20 PostScript language reference manual, 2nd edition ISBN 
0-201-18127-4, chapter 4.7 on pages 172 to 175 
describes the concept and the use of forms. A fixed tem- 
plate can be defined in a form, and the variable informa- 
tion can be painted on top of it. Each execution of the 

25 form will produce the same output. The graphical output 
of the form is saved in a cache. Each time the form is 
used, the saved output may be retrieved instead of re- 
executing the form's definition. The manual states that 
this can significantly improve performance when the form 

30 ts used many times. The way of caching is implementa- 
tion dependent In most implementations, the cache 
stores an internal representation - a display list - that is 
converted to a bitmap each time the form is required. 
Anyhow, if a form contains an image, the whole image 

35 must be cached, which requires a substantial amount of 
memory. Moreover, the generation of a bitmap from the 
display list still requires as serious amount of work. 

None of the above described methods give a satis- 
factory solution to the problems sketched herein before. 

40 

Objects of the invention. 

It is therefore a first object of the invention to provide 
a method that generates high quality pages having an 
45 identical background image and a specific image on 
each page. 

It is a further object of the invention that each page 
is generated in a single print pass. 

It is a specific object of the invention that the com- 
so putational effort to generate pages following the first 
page is substantially reduced with respect to the work 
required to generate the page specific image region. 

Other objects will become apparent from the 
description hereinafter. 

55 

Summary of the invention 

In accordance with the present invention, a method 
is disclosed for printing a plurality of pages, having an 
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identical background image region and at least one page 
specific image region, comprising the following steps : 

a) generating a bitmap representation for said back- 
ground image region and storing said bitmap in a 
bitmap memory means ; 

b) saving in a cache memory means portions of said 
bitmap representation corresponding to each page 
specific image region; 

c) generating a bitmap representation for at least 
one page specific image region and storing said 
page specific bitmap in said bitmap memory means ; 

d) outputting the contents of said bitmap memory 
means to a marking engine for printing at least one 
page; 

e) restoring at least one said saved portion from said 
cache memory means to said bitmap memory 
means ; 

f) repeating steps c) to e) until said plurality of pages 
is printed. 

The feature that the background region is directly 
converted to a bitmap representation of the background 
image, and not stored in some internal format in a sep- 
arate cache memory for later retrieval as in the imple- 
mentation of the PostScript "form" command has several 
advantages : 

if the internal format is not a bitmap format, the exe- 
cution of the "execforrn" command requires the gen- 
eration of the bitmap ; 

if the internal format is a bitmap format, a large 
amount of cache memory is required for storing the 
form, apart from the memory required for the bitmap 
; moreover the "fornY'-functionality requires that an 
extra non-bitmap copy is retained to allow scaling, 
rotation and other graphical state settings ; 
even if the form is stored in bitmap format the con- 
tents of the separate cache memory must be trans- 
mitted to the bitmap memory each time the 
"execforrn" command is executed. In a 400 dpi A3- 
size colour printer, this can require a data copying 
of 120 MByte, which requires 3 seconds in a system 
having a bus bandwidth of 40 MByte per second. 

According to the method of the current invention, the 
bitmap portions - corresponding to the page specific 
image regions - of the bitmap memory means that must 
be saved, are usually substantially smaller than the 
whole bitmap. This has the advantage that just a small 
amount of memory is required to save the bitmap por- 
tions. Moreover, the saving operation and later on the 
restoring operations do not put a big data transmission 
burden on the raster image processor. 

The steps c), d) and e) that must be executed for 
each individual page are mainly restricted to the bitmap 
generation for the page specific data. The bitmap data 
for the page specific image regions can directly be writ- 
ten into the bitmap memory, as if one single page must 
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be printed. As such, no specific processing for this bit- 
map region or extra processing time is necessary, ena- 
bling the system to make use of the high performance 
processing of usual bitmap generation. The outputting of 

5 the bitmap to the marking engine - step d) - must be done 
in any case. A third essential step e) is the restoration of 
the bitmap data representing the background image. 
Ttiis must be accomplish ed at least for the bitmap portion 
that will be different on the next page. The advantage of 

10 this restoration is that e.g. text can always be overlaid on 
the true background, such that this remains visible where 
no text is painted. On the other hand, a box containing 
the text can also be put over the background, whatever 
is required by the layout. Even the size of this box could 

75 vary between consecutive sheets. 

Such bitmap portions are usually substantially smaller 
than the background bitmap, such that the transmission 
requires a small amount of work, which can be done rap- 
idly. Moreover, the restoration of the background bitmap 

20 is accomplished by a simple copy operation, involving no 
other computational effort. A copy operation can be dra- 
matically optimized, based on hardware capabilities or 
sometimes by specific software implementations in 
machine language or microcode. To optimise this trans- 

2s mission, preferentially each bitmap portion consists of a 
rectangular area with horizontal and vertical sides, which 
fully overlaps one or more page specific image regions. 
A page specific image region can be a rectangle rotated 
over e.g. 30 degrees. In that case, the bitmap portion is 

30 preferentially the smallest horizontally oriented rectan- 
gle, enclosing the rotated rectangle. The page specific 
image region may also be delineated by a polygon or any 
other closed path. The bitmap portion is also in that case 
preferentially the smallest enveloping horizontal rectan- 

35 gle. 

The sheets that must be printed are usually sheets 
of paper. The sheets can be printed single sided or dou- 
ble sided. By a plurality is meant that at least two sheets 
are printed, having the same background image. Usually 

40 a sequence of say hundred of sheets is printed, having 
the same background image. It is also possible that each 
individualised sheet must be printed twice or more times, 
when two or more identical copies are required for each 
specific page. It is also possible that the same "back- 

45 ground image" appears e.g . four times on one sheet, and 
that on that sheet four individual pages are prepared. 
The four "background images" form in that case one 
large "background image" in the teaching of this inven- 
tion and the sheet then contains four, eight, .. sheet spe- 

50 cific image regions. A background data stream 
describing such type of pages is usually obtained by 
"step and repeat" imposition, in the case that each 
required sheet fits two or more times on one printed 
sheet. 

55 It is also possible that each individual document con- 
sists of two or more sheets. In that case, preferentially 
the first pages of each individual document are gener- 
ated and output to the printer first, followed by the second 
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pages of each individual document. The documents can 
then be sorted and assembled in a further pass. 

The identical background image region is that part 
of the sheet that carries an image that appears on each 
sheet. The background image can be just printed text, or s 
graphics or the reproduction of a contone image, or any 
combination of these "graphical objects". The graphical 
objects can be in black and white or in colour. A contone 
colour or black and white image can be reproduced on 
each sheet by binary halftoning, by multilevel halftoning 10 
or by a contone reproduction process. Depending on the 
binary, multilevel or contone process, the bitmap 
requires per pixel one or more information bits (binary 
digits) per colour in the bitmap memory means. 

A specific image region can contain personal iden- is 
t'rfication data such as a person's name, address, etc., a 
digital representation of a person's photograph, a 
numeric representation or a barcode for a person's reg- 
istration number, etc. The specific image region can also 
describe a specific item, such as a specific house in a 20 
real estate database, or specific object in a collection. 
The page specific image region can lie completely within 
the background image region, partly overlap it or be com- 
pletely disjunctive from it. It is also possible that more 
than one page specific image region is present on each 25 
sheet. It is possible for example that a person's name 
appears on two different locations of the sheet, or that 
his name appears at one page specific image region and 
his picture appears on another page specific image 
region. If more than one page specific image region is 30 
present, it is possible that these regions partly or entirely 
overlap. 

Generating a bitmap representation is the process 
to convert one or more data streams describing the 
image(s) to be printed on the sheet, in a format that com- 3S 
plies with the spatial and density resolution of a raster 
output device that will print the sheet. A raster output 
device virtually divides the sheet in connected rectangu- 
lar cells, called output pixels or recorder elements, and 
has the capability to address each recorder element incfi- 40 
vidually to assign a specific density level to it. Per 
recorder element, or per group of recorder elements, the 
bitmap needs one memory cell, to keep a representation 
for the density to be assigned to the corresponding 
recorder elements). In binary raster output devices, two 45 
density levels can be assigned to or rendered on each 
recorder element. For this type of devices, the bitmap is 
usually contained in a large memory array or matrix hav- 
ing one bft - capable to store a one or a zero - for each 
individual recorder element. For raster output devices, so 
having a higher density resolution than just two levels, 
more than one bit per recorder element may be neces- 
sary for each recorder element. The memory means, in 
which the bitmap representation for the image to be 
printed on the sheet is stored, is called the bitmap mem- ss 
ory means. This bitmap memory means can be realised 
by a random access memory (RAM) or for example a 
magnetic disk Once a sheet must be printed, the con- 
tents of this memory means is sent to the printer engine, 
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that converts the electrical signals representing the bit- 
map to a visible image on the sheet. 

A specific feature of the current invention is that one 
or more portions of said bitmap representation are 
extracted from the bitmap memory means, once the bit- 
map representation for the background image region has 
been generated. Each portion preferentially corresponds 
to one page specific image region. The portion that is 
extracted preferentially coincides with the page specific 
image region or, as described above, is an enveloping 
rectangle comprising said page specific image region. If 
the output device has a binary density rendering capa- 
bility only, the bitmap memory stores one bit per recorder 
element If the boundary of the page specific image does 
not coincide with a byte boundary (eight bits are usually 
grouped in one byte), it is advantageous to save the 
whole byte comprising the boundary bft, or even to save 
a bigger memory unit such as a word of sixteen or thirty 
two bits. Each bitmap portion is stored in a cache mem- 
ory means. This is a memory means that has no overlap 
with the bitmap memory means, but can be located on 
the same physical medium. The cache memory means 
may be random access memory (RAM), but it can also 
be located on a magnetic disk device. If the bitmap por- 
tions are relatively small and fast access is required, they 
can be stored in RAM. If these portions can be large, 
then they are preferentially stored on a less expensive 
medium such as a disk. 

In the same way as the background image is con- 
verted to a bitmap representation and stored in the bit- 
map memory means, the page specific data are 
converted to a bitmap representation and stored in said 
bitmap memory means. If two page specific image 
regions are present on each sheet, it is possible that one 
such region remains unchanged over two or more con- 
secutive pages, while another region changes from page 
to page. This is e.g. the case when each person acquires 
two or more differently numbered personalised tickets. 
In that case two options are open, in the first way of work- 
ing, each time the bitmap for both image regions (name, 
number) is generated and stored in the bitmap memory 
means. In the other option, only the bitmap for the vary- 
ing region (number) is generated and stored in the bit- 
map memory means, while the other region (name) is 
left unchanged, for it contains the right image printed on 
the previous sheet and not erased by the previous 
restoring step. 

Once the background image and page specific data 
are in bitmap representation in the bitmap memory 
means, the contents of said memory means can be 
transmitted to a marking engine for converting the bitmap 
representation to a density distribution on the sheet. 
Usually one sheet must be printed for each specific doc- 
ument. It is possible however, that each document must 
be available in two or more copies. It that case, the con- 
tents of the modified bitmap memory means can be out- 
put as many times to the marking engine as copies are 
required. 
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Once the modified bitmap memory contents is 
printed as required, the bitmap memory can be prepared 
for the next sheet to be printed. If just one page specific 
image region is present, the bitmap portion saved in the 
cache memory means is retrieved and restored in its 
original location in the bitmap memory means. At that 
moment, the bitmap memory means contains the back- 
ground image representation as it was generated in the 
first stage. If two or more image specific regions (cfr. 
name, number) are present on each sheet and depend- 
ent on which of the above two options is selected (i.e. 
restore each region or just the one that will change), one 
or more bitmap portions are retrieved from the cache 
memory means and restored in the bitmap memory 
means. If the second option is selected, sometimes the 
bitmap memory means does not contain the original 
background image representation. 

The above steps of generating the page specific bit- 
map, printing the sheet and restoring the bitmap portion 
are repeated over and over until all pages are printed. 
The restoration of the bitmap before the first sheet print 
or after the last sheet print is optional, and can be effec- 
tuated or not, based on organisational considerations. 

Detailed description of the invention. 

The invention is described hereinafter by way of an 
example with reference to the accompanying figures 
wherein : 

Fig. 1 shows a specific embodiment 

for carrying out the method 
according to the current inven- 
tion ; 

Fig. 2 shows the logical relation 

between various application 
programs that can be used to 
carry out the invention ; 

Rg. 3 shows a set of OPI-comments, 

describing the inclusion of 
image data ; and 

Fig. 4.A, 4.B and 4.C show excerpts of a PostScript 

data stream for carrying outthe 
invention. 

Fig. 1 shows a configuration on which the method of 
the current invention can be carried out. The system can 
be used for example in a desktop publishing environment 
and comprises a workstation 21 for creating a page lay- 
out, and for generating the page specific data elements. 
The system usually comprises a magnetic hard disk 22, 
for permanently storing elements for composing the 
background image, like digitally scanned images, graph- 
ics such as logo's and font descriptions, as well as data- 
bases containing individual records for the page specific 
image regions and executable programs for performing 
operations on the data. The workstation can also be cou- 
pled directly to an image scanner for image acquisition, 
or images can be transmitted to it via a network, mag- 



netic or optical carriers etc. The workstation is further 
coupled to a raster image processor (RIP) 23 in a point 
to point or network connection, or off line via magnetic 
or optical carriers. As will be described below, the work- 
5 station generates a data stream describing the back- 
ground image and the page specific image data, usually 
in a page description language such as PostScript This 
data stream is accepted by the raster image processor 
23, that converts it to a bitmap representation. This bit- 
to map representation is stored in a bitmap memory 
means, which is usually a random access memory (not 
shown) within the raster image processor 23. The bitmap 
portions are saved on a cache memory means, which 
may be a hard disk 26. 

15 The electrical signals corresponding to the bitmap 
representation are sent from the raster image processor 
23 to the marking engine 24, which renders the repre- 
sentation on a physical medium, like a stack of printed 
sheets 25. 

20 The workstation 21 can be a Mac Quadra 800, con- 
figured with AppIeTalk or EtherTalk. Preferentially the 
operating system running on it is Macintosh System 7, 
supporting LaserWriter printer driver version 7 and 
Ethertalk phase 2. 

25 To carry out the method of the current invention, 
preferentially the following application programs run on 
the workstation 21 : 

a digital image creation program 
30 - a page layout program for creating a data stream 
MASTER.PS 

a database application program for creating data 
streams VDFx.PS 

a variable data field (VDF) merger for combining the 
35 MASTER.PS and VDFxPS data streams. 

A suitable digital image creation program is Pho- 
toshop version 2.5.1, which is a trade mark of Adobe 
Systems Inc. 

40 The page layout program may be QuarkXpress ver- 
sion 3.3, which is a trade mark of Quark Inc. ; or Page- 
Maker version 4.2 or 5.0. which is a registered trademark 
of Aldus Corporation. This is a professional page layout 
program integrating colour, image data, graphics and 

45 text and generating an Encapsulated PostScript or EPS- 
file. It generates one or more page sections, each page 
section describing a background image, along with the 
positional parameters of each page specific image 
region. 

so Trie database application program generates for 
each page specific image region x. from data in a data- 
base format, a PostScript compatible output data stream 
VDFx. PS, which can be directed to a PostScript compat- 
ible printer for immediate output or to a file. Each 

55 VDFx.PS data stream is used as a plug-in in the MAS- 
TER.PS data stream by the variable data merger. A suit- 
able database application program is FileMaker Pro 
version 2.0, a trade mark of Claris Inc. 
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The raster image processor (RIP) 23 can be an Agfa 
CR-A system, CR-A is a trade name of Agfa-Gevaert 
N.V. in Mortsel Belgium. The CR-A RIP supports Post- 
Script level 1 and an extra feature to enable the method 
of the current invention. The system comprises two s 
Motorola MC68040 processors, operating at a clock rate 
of 33 MHz, it further contains an Agfa specific CVl inter- 
face board to drive the marking engine 23. The system 
further comprises a SCSI interface board towards a 340 
MByte SCSI compatible hard disk 26, and an ethernet 10 
connection 27 to hook the raster image processor 23 up 
to the same network as to which the workstation 21 is 
connected to. The CR-A RIP further comprises a random 
access memory board (not shown), capable to store 1 28 
MByte, with an access time of 80 nanoseconds. w 

The marking engine 24 is preferentially an XC305 
or XC31 5 Agfa Colour Copier, both trade names of Agfa- 
Gevaert N.V. in Mortsel, Belgium. 

A A way for carrying out the invention is now 
described in conjunction with Fig. 2. If the background 20 
image comprises digital images, obtained for example 
from contone colour images on photo prints, the digital 
image source files can for instance be generated by the 
above mentioned Photoshop application program 30, 
and saved according to the TIFF (Tag Image File Format, 2s 
trade mark of Aldus Inc.) specification on hard disk in a 
file called TIFF.EPS 31. For each page specific image 
region preferentially a separate dummy TIFF f Be, with the 
extension .VDF is created by Photoshop. The dummy file 
30 for the first page specific image region 42 can be 30 
called TIFF1.VDF, for the second page specific image 
region 43 TIFF2.VDF 33 eta The contents of these 
TIFFx.VDF image files don't really matter, because their 
contents will not appear In the final VDF. PS combined 
data stream 42. Preferentially they represent low resolu- 35 
tion images, such that they do not add to much data to 
the MASTER.PS file. Alternatively, images comprising 
templates for the real page specific regions can be cre- 
ated, to allow proper alignment with the background 
image, as will be discussed below. 40 

in a next step, a page layout program 34 such as 
QuarkXPress or PageMaker 5.0 is invoked. Usually, first 
a text to be printed on the sheet is imported and shown 
on the screen of the workstation according to the 
selected options such as character font, size and other 4s 
characteristics. All background composition images are 
then "imported" via the page layout program. This means 
that a low resolution version of the background compo- 
sition image as required is shown on the video monitor 
of the workstation 21 , but the whole image is not actually so 
accessed. Each background composition image can be 
positioned relative to the text within the page layout, 
mainly with respect to translation, rotation and scaling. 
If required, more text can be added to annotate the 
Images, text can be reorganised etc. Also theTIFFx.VDF ss 
(32, 33) images, representing the page specific image 
regions, must be properly positioned within the page lay- 
out if each TlFFx.VDF image is just a dummy image, 
the rectangular area of that image can be properly posi- 



tioned with respect to the rest of the layout by translation, 
resizing each side of the rectangle and rotation, over any 
angle. Preferentially, each TIFFx.VDF file contains an 
image representation of one page specific image region. 
If the first page specific image region would contain a 
person's name, then TIFF1.VDF preferentially repre- 
sents an image of an arbitrary name, in the font and size 
as required in the final printed sheet As such, the rec- 
tangular box enclosing that name and occupied by the 
TIFF1.VDF Image can be properly positioned and 
aligned with the surrounding text in the background 
image. This rectangular box must not be resized in any 
dimension, because this would obscure the relation 
between the template on the video monitor of the work- 
station and the final result. Another way to properly along 
the page specific image region within the background 
image is to incorporate part or the whole test line, where 
the page specific data are located, in the region. The 
region is positioned as correctly as possible in a first 
pass, and after printing one document, and measuring 
the dislocation, re-positioning the region. 

The page layout program will generate an output 
data stream 35 in a selected page description language. 
Preferentially, the PostScript Level 1 output format is 
selected. The output data stream is preferentially 
directed to a file on hard disk, which we will call the mas- 
ter file MASTER. PS. This master file gives a full descrip- 
tion of the background image. The image data, both 
representing the background composition images and 
the dummy templates for the page specific image data, 
may be effectively included in the master file, preferen- 
tially in a low resolution format, but are also referenced 
by it through the file name. The way how an image is 
referenced to in a PostScript file, is defined by the OP I 
(Open Prepress Interface, trade mark of Aldus Inc.) 
standard, as described in the Open Prepress Interface 
Specification 1.2. In Rg. 3, we show an excerpt from a 
PostScript output of PageMaker 5.0. The comments - 
having a leading % character - define according to the 
OP I standard the image filename as T1FF1 .VDF in the 
"%ALDImageFileName: "-field and further indicate that 
the image data are in TIFF format. The dimensions of 
the image are indicated as 142 pixels by 142 lines, and 
the rectangular areathatthe image will occupy in the lay- 
out is given as measured in points (1 772) under the com- 
ment ^ALDlmagePosition: This means that the size 
of the image and its location within the layout is given. 
The image data is inserted just after the M %%BeginData" 
comment line. The "is CL A " command will consume 
these data such that they are directed to the correct posi- 
tions within the bitmap. The rectangular area delineated 
by the four corner points given in the "%ALDImagePosi- 
tion" comment defines the positional parameters for the 
page specific image region, such as location, shape, size 
and orientation of the region. All page specific data must 
fit within this area. As will be described below, everything 
page specific outside this area will be clipped. 

Once the layout for the background image, along 
with the positional parameters for the page specific 
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image regions, is fixed, the information contents for each 
individual page specific image region on each sheet 
must be generated. As shown in Fig. 2, this is preferen- 
tially done by a database application program 37 such 
as FileMaker Pro version 2.0. In this program, a set of 5 
records can be imported by manual entry or by access- 
ing data on a database file 36. Each record contains indi- 
vidual fields. A record contains for example the 
information about a client. A first field in the record gives 
his last name, the next field his first name, the next field 10 
his address etc. The application program 37 allows to 
pick some fields and format the data in a specific layout. 
According to the above example, one could define a lay- 
out containing two lines : the first line represents the con- 
tents of the last name field followed by the first name field 15 
and the second line represents the contents of the 
address field. The application program 37 can now gen- 
erate a first ASCII PostScript Level 1 compatible page 
specific data file 38 - which we will call VDF1.PS - that 
contains the thus formatted representation of all or a 20 
selection of some records from the database, without 
cover page inclusion. If that file VDF1 .PS would be sent 
to a PostScript printer, one page for each record would 
be generated, each page containing two lines, formatted 
as described above. The text lines, graphical data or 25 
image in VDF1.PS must be positioned relative to a 
known reference, e.g. the lower left corner of each page, 
which is the origin position for the PostScript interpreter. 
This lower left corner will then be positioned upon the 
lower left corner of the rectangular page specific image 30 
region within the background image. 

The VDF1 .PS could reflect the address section of a 
letter, while further down the letter just the last name 
must be inserted in the background image. For that pur- 
pose, a second page specific PostScript data file 35 
VDF2.PS 39 can be generated, extracting from the data- 
base the same records as VDF1. PS, but formatting just 
one line containing each time the last name field of the 
record. Printing VDF2.PS would generate the same 
amount of pages as with printing VDF1 .PS, but on each 40 
page just the last name would appear. 

For every dummy file TIFFx.VDF (32, 33), a corre- 
sponding page specif ic data file VDFxPS (38, 39) must 
be generated. Usually the number of TIFFx.VDF files is 
the same as the number of VDFx. PS files. It is possible 45 
however that the contents of one VDFxPS file can be 
used for two different page specific image regions. If for 
these regions a different dummy file TIFFxVDF and 
TIFFy.VDF were generated, it may be appropriate to 
generate just one VDFx. PS. In this case it could have so 
been also appropriate to reference in the MASTER.PS 
PostScript file two times to the TIFFx. VDF file. 

Usually all page specific image files VDFxPS, 
VDFy.PS, ... represent the same amount of pages. As 
such, the first sheet of the final printed output would con- ss 
tain data corresponding to the first page section 
described in VDFx.PS and the first page section 
described in VDFy.PS. The same applies for the second - 
and all subsequent pages. It is possible however to gen- 



erate a VDFxPS file describing N+N pages, and a 
VDFy.PS file describing just two pages. The first printed 
sheet would then contain the contents of VDFxPS page 
section 1 and VDFy.PS page section 1 ; the second page 
would contain the contents of VDFx.PS page section 2 
and VDFy.PS page section 2 ; the third page would con- 
tain the contents of VDFx.PS page section 3 and 
VDFy.PS page section 1 again, because VDFy.PS was 
exhausted and is cyclically repeated ; the fourth page 
would contain the contents of VDFx. PS page section 4 
and VDFy.PS page section 2, etc. 

Once both the master file MASTER.PS 35 and the 
page specific image files VDFx.PS 38. 39 are created, 
these files can be combined to yield the desired result. 
Therefore a variable data field application program or 
variable data merger 40 is invoked, offering the following 
options. 

The number of copies for each individual sheet can 
be selected. If every document needs two or more iden- 
tical copies, this is set by this number of copies. The 
paper size on which the background layout must be 
printed can also freely be selected. All images refer- 
enced to in the OP I compatible commands must be 
retrieved and explicitly included. These dummy images, 
referenced by a file extension .VDF must not be included 
as such but must be handled as described below. The 
variable data merger will generate an ASCII PostScript 
Level 1 compatible combined data stream 41 . This data 
stream can be directed to a file, e.g. on hard disk or 
directly to a printer system, that accepts a PostScript 
page description language and prints the images repre- 
sented by the language. If the data stream is directed to 
a file, this file can be stored temporarily on a storage 
medium and be sent at a later date be sent to a Post- 
Script compatible printing system. 

The variable data merger 40 will analyze the MAS- 
TER.PS file 35 and locate all the occurrences of a refer- 
ence to a file with extension .VDF. According to the above 
example, the program will find TIFF1.VDF. TIFF2.VDF. 
The program will prompt the operator for the substitution 
of the TIFF 1. VDF reference. According to the above 
example, the operator would introduce the filename 
VDF1 PS. The program then prompts for the substitution 
of TIFF2.VDF ; the operator will introduce VDF2.PS, etc. 

According to the PostScript code in Fig. 4, we will 
describe now how the variable data merger 40 processes 
the different input files : one MASTERPSfile 35, several 
VDFxPS files 38, 39 and possibly different TIFF-f iles 31 
representing images that must be included In the back- 
ground image. Therefore we need to recall how a Post* 
Script file is structured according to the DSC 
recommendations. 

According to DSC, as defined in the Document 
Structuring Conventions in the above mentioned Post- 
Script language reference manual on pages 61 1 to 708, 
a PostScript file contains three main sections : 

a prolog script ; 
a page section ; and 
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a document trailer 

The prolog script further comprises : 

a header section ; 

a procedure section ; and 

a document setup. 

The procedure section gives the definition of proce- 
dures in terms of regular basic PostScript expressions, 
which will mainly be used in the document setup and 
page sections. The document setup performs initialisa- 
tions which are valid for all subsequent pages of the doc- 
ument The page section contains for each subsequent 
page the commands which are necessary to paint the 
bitmap representing the page completely and to issue 
the bitmap contents to the marking engine. Each page 
within the page section starts - according to the DSC 
conventions - with a "%%Page L N" comment, wherein 
L represents a label and N represents the page number 
in arabic numerals. The trailer section starts with the 
comment line "%%Trailer" according to the DSC conven- 
tions. 

The variable data merger application program cre- 
ates its output data stream in the fol lowing way. A specific 
header section is created. Then the MASTER.PS file is 
read, and the .VDF file references and templates are 
replaced by the output generated by the database appli- 
cation program. The general structure of the data stream 
created by the variable data merger can be summarized 
as follows : 

Definition of variable data merger specific proce- 
dures 

Prolog section of MASTER. PS file (PageMaker out- 
put) 

Page section of MASTER.PS file - Page 1 only 

(PageMaker output) omission of "%%BeginObject .. 

%%EndObject n if .VDF image 

Save all bitmap portions according to page specific 

regions 

For each page in VDFxPS : 

+ Translate and rotate co-ordinate system to 
lower left corner of page specific region 

+ Prolog section of VDFx.PS file (FileMaker Pro 
output) 

+ Page section of current page in VDFxPS file 
+ Trailer section of VDFxPS file (FileMaker Pro 
output) 

+ Issue modified "copypage" command also 
restoring all saved bitmap portions ("showpage" 
on last page also removing all saved bitmap por- 
tions from cache memory) 

- Trailer section of MASTER. PS file (PageMaker out- 
put) 



We will discuss each above section more in detail. 
The definition of variable data merger specific proce- 
dures is in fact an application specific procedure section. 
In Fig. 4.A a "PageSizeRequest" procedure is defined 
5 that must be executed whenever a page size initialisation 
or the like is done, if this is done during the processing 
of a VDFxPS file, then the standard PostScript "info- 
graphics" procedure is invoked and the page specific 
image region is defined as clip region, such that nothing 
10 can be painted outside this region. Next all types of page, 
paper tray and page device requests (ag. /a3, etc..) are 
intercepted and converted to the execution of the above 
PageSizeRequest command. A context save and restore 
procedure are defined, that cope with database applica- 
nts tion programs that leave dictionaries on the stack. 

In Fig. 4.B the standard "showpage" and "copypage" 
commands are redefined such that the required number 
of copies for each page are printed. As will be discussed 
below, the "/showpage" and "/copypage" procedures 

so have a specific side-effect, to carry out the invention, fur- 
ther the AGFA_MAKE_TRANS_FROM_RECT com- 
putes translation and rotation parameters from a set of 
rectangle coordinates obtained from the OP1 comments 
in the master file and stores these corner points for use 

25 in the PageSizeRequest. The AGFA_CLEAR_RECT 
command clears the current page specific image region 
if the raster image processor does not support the "set- 
variabledatabox"-procedure, which will be discussed 
below. If the RIP does support this command, basically 

30 nothing special is done. In the AGFA_SAVE_V DF_BOX, 
we see the use of an AgfaScript (trade mark of Agfa- 
Gevaert A.G. in Leverkusen, Germany) specific com- 
mand. AgfaScript is a PostScript language interpreter. 
The setvariabledatabox command has consumes five 

35 param eters from th e stack : 

1) bitmap_portion_id : unique identifier to refer to 
one specific bitmap portion ; . 

2) bitmap_portionJeft : most left position of bitmap 
40 portion 

3) bitmap_portion_bottom : bottommost position of 
bitmap portion 

4) bitmapjaortionjight : most right position of bit- 
map portion 

45 5) bitmap_portion_top : topmost position of bitmap 
portion 

Execution of this command will transmit a horizontal rec- 
tangular portion of the bitmap from the bitmap memory 

so means to the cache memory means. As will be described 
below, "copypage" restores all bitmap portions saved by 
this command, and "showpage" removes all these bit- 
map portions from cache memory. 

Finally, the usual "showpage"-command is rede- 

ss fined such that it has no effect when invoked by the page 
layout or database programs. 

The prolog section of the MASTER.PS PageMaker 
output file starts at the beginning of the MASTER.PS file 
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and proceeds up to (but not including) the first DSC 
"%%Page"-comment 

The page section starts at said "%%Page"-comment 
and proceeds up to (but not including) the next DSC 
"%%Page"-comment or the DSC "%%Trailer" -comment 5 
The contents of this page section is scanned and output 
until an OPI-comment line referencing to a .VDF file is 
found. In that case, the next section enclosed by 
"%%BeginObject: image" and "EndObject", as shown in 
Fig. 3, is removed from the output data stream. The rest 10 
of this page section is further transmitted to the output 
data stream. Wherever a non-.VDF-f He must be included 
for background images, it is added to the output data 
stream. Once this page section from the master-file cre- 
ated by Pag eMaker is fully transmitted to the output data is 
stream, the background image is fully painted in the bit- 
map memory means and the image specific regions 
must now be filled in, in a loop over all data records. 
Before this procedure is started, the full status is saved 
by the execution of the n __AGFA_SAVE_CONTEXT'- zo 
procedure. A shorthand for the rectangle coordinates for 
each image specific region is defined (e.g. 
_AGFA_VDF_RECTJ1 definition). Eight numbers 
defining the position of the four corner points of a rotated 
rectangle are required. These numbers are retrieved 25 
from the OPI-commerrts, as described above, and define 
the positional parameters of the page specific image 
region. 

Every portion from the bitmap memory means cor- 
responding to a page specific image region is saved by so 
a function that invokes the AgfaScript specific "setvaria- 
biedatabox"-command : 

e.g. 1 396 650 538 793 _AGFA_SAVE_VDF_BOX. As 
described above, such a portion is a horizontal rectan- 
gular area, completely covering the page specific image 35 
region. The co-ordinates of the lower left and upper right 
corner of this portion are sufficient to fully describe it If 
the current sheet contains more than one page specific 
image region, a plurality of such commands, to save a 
bitmap portion in cache memory, will be issued, prefer- 40 
entially one per region. 

Then the loop for each page in the VDFx.PS f ile cre- 
ated by FileMaker Pro can be started. The first thing to 
happen is clearing the page specific image region for 
RIP's that do not support "setvariabledatabox". This is 45 
done by the commands _AGFA_VDF_RECT_1 1 and 
_AGFA_CLEAR_RECT. The last command clears the 
area if said command is not known. Next the graphical 
state is saved in a standard PostScript "gsave" com- 
mand. Then the origin is translated to the lower left cor- so 
ner of the rectangular page specific image region and 
the correct rotation of this rectangle is performed, by the 
_AGFA_VDF_RECT_1 1 and _AGFA_MAKE_TRA- 
NS_FROM_RECT commands. By the last command 
also the data falling beyond the rectangular page specific ss 
image region provided for the region are clipped. This 
has the advantage that the background image will not be 
disturbed outside the region. 



Next the prolog section of the VDFxPS file is trans- 
mitted to the output data stream. The prolog section 
starts from the beginning of the file VDFx. PS file and pro- 
ceeds up to (but not including) the first DSC "%%Page"- 
commerrt. After this section, the appropriate page sec- 
tion for the current page must be added. This section is 
found by scanning the VDFx.PS file, until a "%%Page L 
N"-comment with the right page number N is found. Eve- 
rything from this location in the VDFxPS file up to (but 
not including) the next DSC "%%Page M -commerrt or the 
DSC "%%Trailer M -comment within the VDFx. PS file is 
included in the output data stream. This data stream will 
paint the page specific image region with the appropriate 
graphical data in the bitmap memory means. After this 
operation, the bitmap is ready to be printed. The single 
page section is then followed by the trailer section from 
the VDFxPS file created by FileMaker Pro. This trailer 
section starts with the DSC "%%Trailer"-comment and 
stops at then last character in the VDFxPS file. 

. Then the graphical status, valid before the above 
mentioned w gsave"-command, is restored by a standard 
PostScript "grestore" command. The previous transla- 
tion and rotation are thus restored. The bitmap memory 
means is now printed by the __AGFA_COPYPAGE com- 
mand. This will issue the contents of the bitmap memory 
means towards the marking engine, that converts the bit- 
map representation to an optically visible image on a 
sheet The contents of the bitmap memory is not lost by 
this operation. This modified "copypage" command will 
issue that amount of identical copies which is required 
by the variable data merger operator. The modified "cop- 
ypage" command has another AgfaScript specific side- 
effect. Once all required copies are printed, all rectangu- 
lar portions - saved in cache memory means by the "set- 
variabledatabox"-command - are restored in the bitmap 
memory means. As such, the background image is com- 
pletely restored in the bitmap memory means. 

If more pages are present in the VDFx. PS file, the 
procedure starts again : clear the page specific image 
regions on a PostScript device not supporting "setvaria- 
bledatabox" ; save graphical state ; translate, rotate & 
clip rectangle ; issue FileMaker Pro prolog ; select and 
issue correct page section ; issue Filemaker Pro trailer 
section ; restore graphical state ; issue the modified "cop- 
ypage" command to render the required pages and 
restore the rectangular bitmap portion(s) and restart the 
procedure. 

If the last page according to the VDFx.PS file must 
be printed, the modified "copypage" is substituted by a 
modified "showpage" command, that issues as much 
identical copies as is required by the variable data 
merger application program operator, but the contents of 
the bitmap memory is lost by this operation. The contents 
of the bitmap memory means is reset to represent a 
"blank page", ready to accept the data for the next page. 
The modified "showpage" command has another AgfaS- 
cript specific side-effect Once all required copies are 
printed, all rectangular portions - saved in cache memory 
means by the "setvariabledatabox"-command - are 
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erased from the cache memory means. As such, these 
portions are made inaccessible, even for subsequent 
AgfaScript specific "copypage" or "showpage" com- 
mands to come. 

After the last modified "showpage" command, the s 
full context, which was stored by the 

" AGFA_SAVE_CO NTE XT" command, is now 

restored by the M _AGFA_RESTORE_CONTEXT com- 
mand. And finally the trailer section from the MAS- 
TER. PS file - output from PageMaker - is issued in the 10 
output data stream. This trailer section starts at the DSC 
"%%Trailer"-comment and ends at the last character of 
the MASTER.PS file. 

The above description is confined to a one sheet 
background image and one page specific image region is 
within the background image. The master file may how- 
ever contain more pages. In that case, preferentially first 
all sheets corresponding to the first page section in the 
MASTER. PS file are printed ; thereafter, all sheets cor- 
responding to the second page section in the MAS- 20 
TER.PS file are printed etc. To accomplish this, the step 
where the trailer section of the MASTER.PS file is intro- 
duced in the output data stream, is postponed and 
replaced by an iteration that restarts at the output of the 
page section of the MASTER.PS file - Page 2 only. The ss 
other steps follow the same sequence as for page 1 in 
the MASTER.PS-file. As usual, the page section starts 
with the DSC "%%Page"-comment and ends where the 
next "%%Page"-comment appears, or the final 
"%%Trailer , '-comment P which terminates the last page 30 
section. As long as the "%%Trailer-comment is not met, 
the process iterates for handling a next page section of 
the MASTER. PS file. Once the trailer section is encoun- 
tered, the current page section of the MASTERPS file 
is processed, by inclusion of the expanded VDFx.PS- 35 
file(s), and the output data stream is concluded by the 
trailer section of the MASTER.PS file. 

It is also possible that a page section of the MAS- 
TER.PS file refers to more than one VDFxPS file, say 
VDFxPS and VDFy.PS. In that case the 40 
AGFA_SAVE_VDF_BOX will be invoked for two bitmap 
portions, each enclosing one of both page specific image 
regions. The issuance of the modified "copypage" or 
"showpage" command is postponed to happen after a 
new iteration of translation and rotation, prolog section 45 
of the VDFy.PS file, page section of the current page in 
the VDFy.PS file and trailer section of the VDFy.PS file. 
If yet a third VDFxPS file was referred to in the current 
pageof the MASTER.PS file, then again the process iter- 
ates from the translation and rotation. After the "current so 
page" of each referenced VDFx.PSfile is included, along 
with the corresponding prolog and trailer section, a mod- 
ified "copypage" command - or for the last page section 
in VDFxPS-file a modified "showpage" command - is 
issued, and then the next page section or the final trailer 55 
section of the MASTER.PS file is handled. 

If more than one page specific image region is 
present in a background image region, it is possible that 
two or more of these image regions have overlapping 



portions. In that case, it is important to decide which page 
specific image region must be visible over the other for 
the common portion. This overlap sequence must be 
transmitted to the variable data merger. That sequence 
will impose the order in which each current page of the 
plurality of VDFxPS files will be included in the data 
stream. A VDFx.PSfile, describing a page specific image 
region which is covered by a page specific region 
described by a VDFy.PS, will appear in the output data 
stream for each page before the VDFy.PS file data. 

Another important advantage of the method accord- 
ing to the current invention is the independence of the 
VDFxPS files from imposition. Several background 
images can be prepared, e.g. by the PageMaker appli- 
cation program, resulting in an output file MASTER.PS. 
An imposition program re-arranges the page sections of 
the output file MASTER.PS and includes translations 
and orthogonal rotations required to position correctly 
one or more background images on a sheet, such that 
one or more sheets can be folded and constitute a logical 
sequence of the different pages. When creating the 
MASTER.PS file, the page specific image regions can 
be correctly located within the background image. 
According to the OP I recommendations, the location and 
orientation of these page specific image regions is 
encoded in the MASTER.PS file. This file refers to vari- 
ous dummy image files, which must be finally substituted 
by the page specific data. The file can be offered to an 
imposition application program, that transforms the 
MASTERPS file to e.g. as MASTERI.PS file. The OPI- 
comments that describe the positional parameters of the 
dummy image files to be included, have been changed 
by the imposition program according to the new location 
and orientation of the background image. The most 
important advantage to incorporate page specific image 
regions in the background layout as dummy images, is 
the fact that they are referenced by the OP I comments, 
via their filename plus extension and that the positional 
parameters within the background image are also indi- 
cated by the OP I comments. The variable data merger 
can easily retrieve the spots where the variable data 
must be introduced, and the positional parameters are 
taken care of by OP I compliant applications such as most 
imposition programs. This way, different applications 
such as a professional page layout application and a 
database application can be merged, without the need 
to integrate or completely rewrite them. The variable data 
merger program can now operate in the same way on 
the MASTERI.PS file as it worked for the MASTERPS 
file. Every VDFx. PS f ile, which is necessary to obtain the 
final result, does not need to have knowledge about the 
imposition that has been performed. This also alleviates 
the burden on the imposition program. This has to proc- 
ess only the data within the MASTERPS file describing 
the background image(s), and no page specific data at 
all, which can be a substantial amount of data if a lot of 
records in the database are concerned. 

Having described in detail a preferred embodiments 
of the current invention, it will now be apparent to those 
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skilled in the art that numerous modifications can be 
made therein without departing from the scope of the 
invention as defined in the following claims. 

Claims 

1 . A method for printing a plurality of pages, having an 
identical background image region and at least one 
page specific image region, comprising the following 
steps: 

a) generating a bitmap representation for said 
background image region and storing said bit- 
map representation in a bitmap memory means 

* 
i 

b) saving in a cache memory means portions of 
said bitmap representation corresponding to 
each page specific image region ; 

c) generating a bitmap representation for at 
least one page specsfic image region and stor- 
ing said page specific bitmap representation in 
said bitmap memory means ; 

d) outputting the contents of said bitmap mem- 
ory means to a marking engine for printing at 
least one page ; 

e) restoring at least one said saved portion from 
said cache memory means to said bitmap mem- 
ory means ; 

f) repeating steps c) to e) until said plurality of 
pages is printed. 

2. The method according to claim 1 , wherein said page 
specific image region has a rectangular shape. 

3. The method according to claim 1 , wherein said bit- 
map portion has a horizontal rectangular shape. 

4. The method according to claim 1 , wherein each said 
bitmap portion completely covers at least one said 
page specific image region. 

5. The method according to claim 1, wherein in each 
iteration a bitmap representation is generated for 
each page specific image region, and each saved 
bitmap portion is restored. 



b) generating a page specific data stream 
describing each page specific image region ; 

c) combining said background data stream and 
said page specific data stream ; 

5 d) generating from said combined data stream 

successive sets of marking engine signals rep- 
resenting the background image including each 
page specific region ; 

e) printing the image represented by each suc- 
io cessive set of marking engine signals. 

7. The method according to claim 6, wherein the posi- 
tional parameters include : 

15 - the location relative to said background image ; 
- . the shape ; 
the size ; and 
the orientation. 

20 8. The method according to claim 7, wherein the posi- 
tional parameters further include a reference to an 
image data file. 

9. The method according to claim 8, wherein the step 
25 of combining said data streams comprises the step 

of retrieving said reference to an image data file in 
said background data stream. 

10. The method according to claim 6, wherein the step 
30 of combini ng said background data stream and said 

page specific data stream is preceded by a step of 
performing any transformation on said background 
data stream required for imposition. 

35 11. The method according to claim 6, wherein the step 
of generating sets of signals comprises the step of 
dipping page specific image data, based upon said 
positional parameters. 

40 12. The method according to claim 6, wherein the com- 
bination step comprises the step of ordering the 
processing of each page specific image region. 



45 



6. A method for printing a plurality of pages, having an 
identical background image region and at least one 
page specif ic image region, comprising the following 
steps : so 



a) generating a background data stream 
describing : 

1) said background image region ; and ss 

2) for each said page specific image region 
the positional parameters ; 
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userdict / AGFA Copies 1 put 

/ AGFA_VDF_DICT 100 diet def 

AGFA_VDF_DICT begin 
"~7 AGFA VDF C TM matrix def aultmatrix def 
/PageSizeRequest { 
initgraphics 

AGF A_VD F_D I CT begin 

AGFA_VDF_D ICT / AGFA VDF BOUND known 

( AGFA_VDFJBOUND a load pop newpath move to lineto line to lineto 

cXosepath clip} if 
AGFA VDF CTM setmatrix end 

} def 
end 

/ AGFA Redef If Known { 

currentdict begin 

[0 {" AGF A__VDF_D I CT begin PageSizeRequest end} /exec load] 

2 copy exch 50 string cvs 0 exch put cvx def 
end 

} def 

[/a3 /a4 /A4 /a4small /a5 /A5 /b5 /B5 
/Letter /letter /lettersmall /note /legal /llxl7 /ledger] 
{ AGFA Redef If Known} forall 

statusdict begin 

[ /lettertray /llxl7tray /ledgertray /legaltray 

/statementtray /executivetray /a3tray /a4tray /b4tray /bStray] 
{ AGFA Redef If Known) forall 

/setpapertray dup currentdict exch known 

{{pop AGFA_VDF_DICT begin PageSizeRequest end} bind def} 

{userdict exch {pop AGFA_VDF_DICT begin PageSizeRequest end} 

bind put} if else 

end 

/setpagedevice {pop AGFA__VDF_D ICT begin PageSizeRequest end} def 

AGFA_VDF_DICT begin 

/ AGFA_SAVE_CONTEXT { 

AGFA^VDF_DICT begin dup 3 diet def load end 
TjnumdXcts countdict stack put 

AGFA VDF_DICT begin / AGFA_ContextSave save def end 

) Hef 

/ AGFA_RESTORE_CONTEXT { 

AGFA_VDF__D ICT begin load 

begin 

/__numdicts load 
end 
end 

countdict stack exch sub dup 0 gt 
{ {end} repeat} if 

AGFA VDF PICT begin AGFA ContextSave restore end 
} def 
end 



Fig. 4.A 
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/ AGFA SHOWPAGE {userdict begin 

~ /#copies AGFA Copies def 

systemdict 
/showpage get exec 

AGFA_VDF DICT begin 
7~" AGFA VDF CTM matrix def aultmatrix def 
end) 

def 

/_AGFA_COPYPAGE {userdict begin 

/# copies AGFA Copies def 

systemdict 

/copypage get exec 

end) 

def 

/_AGFA_CLEAR_RECT { 
statusdict~~begin 

statu sdict /setvariabledatabox known 

(8 {pop) repeat) , 
(systemdict begin matrix def aultmatrix setmatrix end initclxp 
newpath move to lineto line to lineto closepath 
currentgray 1 setgray fill setgray} 
ifelse 

) def 

/_AGF A_MAKE_TRAN S_FR0M_RE C T { 

systemdict begin matrix def aultmatrix setmatrix end 
8 copy 8 array astore 

AGFA VDF DICT begin / AGFA_VDF_BOUND exch def end 

8 copy newpath move to lineto lineto lineto closepath clip 
4 { pop ) r epe at 4 copy 

exch 4 1 roll exch sub 3 1 roll exch sub exch atan 5 1 roll 
pop pop translate rotate 

AGFA VDF_DICT begin / AGFA_VDF__CTM matrix currentmatrix def end 

) def 

/ AGFA SAVE VDF^BOX 

(statusdict begin statusdict /setvariabledatabox known 
(matrix def aultmatrix setmatrix setvariabledatabox ) 
(pop pop pop pop pop (ppppp) ==} 
ifelse end 
) def 

/_AGFA_SHOWPAGE_TO_NOTKING (/showpage {) def ) def 
_AGFA_SHOWPAGEJTO_NOTRING 

% PageMaker Prolog section - PageMaker Page section 1 

AGFA VDF DICT begin /savecon / AGFA_SAVE_QONTEXT load end exec 

/ A GF A ^^DE" P*ECT 11 ( 
"396.000 650.500" 396.000 792.500 538.000 792.500 538.000 650.500 

) def 

1 396 650 538 793 AGFA SAVE VDF_BOX 



Fig. 4.B 
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% Start loop over ©different database records 

AGFA__VDF_RECT_1 1 __AGFA_CLEAR_RECT 

gsave 

AGF A_VD F_RE C T_l 1 _AGFA_MAKE_TRANSJFROM_RECT 

% FileMaker VDFx.PS Prolog section ; Page section 1 ? Trailer section 

grestore 

_AGFA_COPYPAGE 

% Second iteration 

AGFA_VDF_RECT_11 _AGFA_CLEAR_RECT 

gsave 

AGFA_VD F__RE CT_1 1 _AGFA__MAKE_TRANS_FROM__RECT 

% FileMaker VDFx.PS Prolog section ; Page section 2 ; Trailer section 

grestore 

_AGFA__COP xPAGE 

% Third iteration 

AGF A__VD F_RE CT_1 1 _AGFA_CLEAR_RECT 

gsave 

AGFA VDF RECT_1 1 _AGF A_MAKE_TRANS_FROM_RE CT 
% FileMaker VDFx.PS Prolog section / Page section 3 ; Trailer section 
grestore 
_AGFA__COP YP AGE 
% Last iteration 

AGFA_VDF_RECT_11 __AGFA_CLEAR_RECT 

gsave 

AGFA_VDF_RECT__1 1 _AGF A_MAKE_TRAN S_FROM_RECT 

% FileMaker VDFx.PS Prolog section ; Last Page section ; Trailer section 

grestore 

_AGFA_SHOWPAGE 

AGF A_VD F_D I CT begin /savecon / AGFA RESTORE CONTEXT load end exec 

% Trailer section of PageMaker output MASTER. PS 

Fig. 4.C 
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